System and method for providing threshold levels on privileged resource usage in a mobile network environment

ABSTRACT

A system and method in one embodiment includes modules for detecting a request by an application in a mobile device to access a privileged resource, determining a cumulative usage of the privileged resource by the application, and performing an action according to a rule if a predefined threshold level of usage triggers the action based on the cumulative usage. More specific embodiments include blocking the request, and sending a notification to a user and updating a rules database to modify the predefined threshold level of usage associated with the rule. Other embodiments include monitoring permissions of the application to the privileged resource, and removing any permissions that have not been used for a predefined time period, logging the request into a log in a utilization database, reading the log, collating information in the log, and analyzing the log.

TECHNICAL FIELD

This disclosure relates in general to the field of computer networks andcommunication and, more particularly, to a system and method forproviding threshold levels on privileged resource usage in a mobilenetwork environment.

BACKGROUND

The field of computer network security has become increasingly importantand complicated in today's society. Computer network environments areconfigured for virtually every enterprise or organization, typicallywith multiple interconnected computers (e.g., end user computers,laptops, servers, printing devices, etc.). In many such enterprises,Information Technology (IT) administrators may be tasked withmaintenance and control of the network environment, including executablesoftware files (e.g., web application files) on hosts, servers, andother network computers. As the number of executable software files in anetwork environment increases, the ability to control, maintain, andremediate these files efficiently can become more difficult.

Moreover, hackers are targeting computer networks and users' sensitiveinformation through mobile devices. Hackers' appetites for the mobilechannel are rising, with one third of smartphone users now accessing theInternet from their mobile devices. Mobile devices are among the fastestgrowing consumer technology, and a variety of mobile applications arepopular in the mobile channel. As mobile devices have grown inpopularity, so have hackers' interests in these devices. Mobile malware,for example, is on the rise, as attackers target mobile phones. Yet, thebalance of innovation versus security in the mobile space is beingchallenged by the industry's desire to attract more developers.Providing open access to application development can drive developerattention and open the door for technology abuse at the same time.Competition among mobile platforms is high, putting pressure on shortingcontent approval cycles and simplifying pre-launch security checks toboost developer time-to-market. The trend of mobile user concentration,opening device platforms and shortened security procedures raisessecurity threats to computer networks and users' privacy fromvulnerabilities in mobile devices.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present disclosure andfeatures and advantages thereof, reference is made to the followingdescription, taken in conjunction with the accompanying figures, whereinlike reference numerals represent like parts, in which:

FIG. 1 is a simplified block diagram illustrating components of a systemfor threshold levels on privileged resource usage according to anexample embodiment;

FIG. 2 is a simplified flow-chart illustrating example operational stepsthat may be associated with embodiments of the present disclosure;

FIG. 3 is a simplified block diagram illustrating components of thesystem according to another embodiment of the present disclosure; and

FIG. 4 is a simplified flow-chart illustrating example operational stepsthat may be associated with embodiments of the present disclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

A system and method in an example embodiment includes modules fordetecting a request by an application in a mobile device to access aprivileged resource, determining a cumulative usage of the privilegedresource by the application, and performing an action according to arule if a predefined threshold level of usage triggers the action basedon the cumulative usage. More specific embodiments include blocking therequest, sending a notification to a user, and updating a rules databaseto modify the predefined threshold level of usage associated with therule. In an example embodiment, the predefined threshold level of usagetriggers the action if the cumulative usage occurs within a predefinedamount of time. In another example embodiment, the predefined thresholdlevel of usage triggers the action if the cumulative usage exceeds thepredefined threshold level of usage.

Other embodiments include logging the request into a log in autilization database, reading the log, collating information in the log,and analyzing the log. An example embodiment includes monitoringpermissions of the application to the privileged resource, and removingany permissions that have not been used for a predefined time period.The user may be notified if the application has not used a permissionfor the predefined time. Other specific embodiments include sending anotification to the user if there are no rules applicable to the requestand other features.

Example Embodiments

FIG. 1 is a simplified block diagram illustrating an exampleimplementation of a system 10 for providing threshold levels onprivileged resource usage in a mobile network environment. A mobiledevice may be provisioned with one or more applications 12. Anapplication includes application software that runs on (or is capable ofrunning on) mobile devices and performs specific tasks for the mobiledevice's user. Applications 12 may include native applicationspre-installed on the mobile device, such as address books, calendars,calculators, games, maps and Web browsers. Applications 12 may also bedownloaded from various mobile application software distributionplatforms such as Google® Android Market, Apple® App Store, Palm®Software Store and App Catalog, RIM® App World, etc. According toembodiments of the present disclosure, mobile devices are inclusive ofmobile phones, smart mobile phones (smartphones), e-book readers,tablets, iPads, personal digital assistants (PDAs), laptops orelectronic notebooks, portable navigation systems, multimedia gadgets(e.g., cameras, video and/or audio players, etc.), gaming systems, otherhandheld electronic devices, and any other similar device, component,element, or object capable of initiating voice, audio, video, media, ordata exchanges.

A monitoring and blocking module 14 may be provisioned to intercept oneor more requests 16 from applications 12 to access one or more resources18 (user herein in the singular as resource 18 to refer to any one ofthe resources). As used herein, the term “access” includes open, create,read, write, modify, delete, execute, or use. As used herein, the term“resource” includes any physical or virtual component within a mobiledevice, such as processors, memory, files, data structures, networkconnections, camera, microphone, etc. The term “resource” also includesany source of data, such as files, registry data, e-mails, SMS, browsercookies, browser history, etc. Data, as used herein in thisspecification, refers to any type of numeric, voice, video, graphic, orscript data, or any type of source or object code, or any other suitableinformation in any appropriate format that may be communicated from onepoint to another in electronic devices and/or networks. For example,application 12 can send request 16 to an email program to open an emailattachment. In another example, application 12 can send request 16 to aport to send data over a wireless network. In yet another example,application 12 can send request 16 to a storage disk to write into afile stored thereon.

Resources 18 may be privileged (i.e., require permission to access).Examples of various privileges include the ability to create a file,read or write into a file, use a device resource such as a camera, reador write to a socket for network communication, etc. Privileges can beautomatic (e.g., applications 12 may be automatically granted permissionto access memory 34), or granted (e.g., a user may grant applications 12permission to access a list of contacts in the mobile device).Monitoring and blocking module 14 may apply rules from rules/filtersmodule 20 to requests 16. Rules can include conditionally executedactions based on occurring events. An example of a rule may includeblocking an outgoing email containing a file that is larger than apredefined threshold size (e.g., 10 MB). Rules may also include filters.For example, a rule may specify a filter that filters requests based ona request attribute, such as a read attribute (e.g., read request) or asend attribute (e.g., send request). In another example, a rule may beset to filter all requests from a specific application.

The rules may be associated with one or more threshold levels 22 (usedherein in the singular as threshold level 22 to refer to any one of thethreshold levels). As used herein, the term “threshold level”constitutes a limit that can trigger actions (e.g., blocking a sendrequest, terminating a process, logging, etc.). The actions triggered bythreshold level 22 may be specified by the rules in rules/filters module20 and can be implemented in any suitable manner (e.g., system 10 may beconfigured to trigger actions if a threshold level is exceeded, met, notexceeded, not met, etc.).

Threshold level 22 may be implemented on any measurable property orparameter associated with resource 18, such as file size, network datasize, central processing unit (CPU) usage (e.g., time and/or amount),number of short message service (SMS) messages, number of permissions inapplications 12, etc. According to embodiments of the presentdisclosure, components of system 10 may set threshold levels 22 onprivileged resource usage (e.g., camera, network etc.) and privilegedinformation access (e.g., reading browser history, reading SMSs etc.) onmobile devices. Some threshold levels 22 may be integrated with a timecomponent (e.g., at least 50 SMS messages sent each day for a certainnumber of days, 50% CPU usage for greater than 5 minutes, a grantedpermission not used within a week, etc.). System 10 can notify user 26regarding privileged resource usage to enable various types of possibleintervention, if threshold levels 22 of such resource usage indicateintervention may be needed.

The rules may be changed, updated, or created by notifying user 26 forpossible intervention. In an example embodiment, the rules may specifythat a notification 24 may be sent to a user 26. In one example, ifthere are no rules applicable to request 16, a default rule may specifythat notification 24 may be sent to user 26. In another example,rules/filters module 20 may send notification 24 to user 26 for anyupdates that may be desired to the rules. User 26 may send an update 28directly to monitoring and blocking module 14, and/or update the rulesin rules/filters module 20. If request 16 is permitted by rule/filtermodule 20, or by an update 28, request 16 may be forwarded to resource18 as appropriate for further processing.

Rules/filters module 20 may include a rules database 30. Rules database30 may comprise rules used by rules/filters module 20 for processingrequests 16. Monitoring and blocking module 14 and rules/filters module20 may use one or more processors 32 and one or more memory 34 toperform their intended functions. Processors 32 and memory 34 may bepart of resource 18. Monitoring and blocking module 14 may also logrequests 16 into one or more logs 36 in a utilization database 38.

For purposes of illustrating the techniques of system 10, it isimportant to understand the activities and security concerns that may bepresent in a given system such as the system shown in FIG. 1. Thefollowing foundational information may be viewed as a basis from whichthe present disclosure may be properly explained. Such information isoffered earnestly for purposes of explanation only and, accordingly,should not be construed in any way to limit the broad scope of thepresent disclosure and its potential applications.

In general, downloadable and native applications can present manysecurity threats on mobile devices. Some applications may bespecifically designed to be malicious, and some other applications maybe easily exploited for malicious purposes. Application-based threatsgenerally fit into one or more of the following categories: (1) malware;(2) spyware; (3) privacy threat; and (4) vulnerable applications.Malware is software that is designed to engage in malicious and/orunwanted behavior on a device. For example, malware can commonly performactions without a user's knowledge, such as making charges to the user'sphone bill, sending unsolicited messages to the user's contact list, orgiving an attacker remote control over the device. Malware can also beused to steal personal information from a mobile device that couldresult in identity theft or financial fraud.

Spyware is software that is designed to collect or use data without auser's knowledge or approval. For example, spyware may automaticallytrigger a camera's phone or microphone, record conversations, recordlocations, etc. and send the collected information to a remoterecipient. Privacy threats may be caused by applications that may not benecessarily malicious, but gather or use information (e.g., location,contact lists, personally identifiable information) that is unnecessaryto perform their primary functions. Vulnerable applications can containsoftware vulnerabilities that can be exploited for malicious purposes.For example, vulnerabilities can often allow an attacker to accesssensitive information, perform undesirable actions, stop a service fromfunctioning correctly, automatically download malicious software, orotherwise engage in undesirable behavior.

Typically, hackers can use the vulnerabilities in mobile devices toaccess information on the mobile devices and on devices in a connectednetwork, such as computer networks, and send the accessed information toremote locations surreptitiously. For example, mobile phonetechnologies, such as Android operating system (OS), provide a richapplication programming framework, which allows application developersto get access to a variety of data like SMS's, phone logs, contactlists, web browsing history, etc. in the mobile devices if they haverelevant permissions. Resources of a mobile phone can also be exploited.For example, malware could send spam mail or unsolicited emails byabusing a user's mobile phone. In another example, a legitimateapplication may request and receive permission to access information andresources, and an attack on the legitimate application could misusethose permissions. The framework also allows applications to accessresources such as an available network, a camera, etc., by requestingpermissions.

Generally, applications explicitly request the user for permission(typically during installation) to access information and resources.However, a user who is not technologically savvy may not understand howthese permissions are used by the applications. Even if the user istechnologically savvy, s/he may not understand how and when thepermissions are used through the life time of the application. Moreover,some applications may require permissions for advertising(location/Internet access) to perform their primary function; however,without adequate controls, the private or sensitive information may besent to unauthorized recipients as well. It may be hard to differentiatelegitimate permissions from illegitimate ones. Applications may notimmediately behave maliciously upon installation; sensitive information(e.g., SMS's with financial information, IMEI number, IMSI number, phonenumbers, etc.) may be sent out many days after the application isinstalled without the user noticing information that is being leaked.

Application-based threats are typically dependent on operating systems,and may affect some operating systems more than others. For example,some malware and spyware target devices operating on Android OS. AndroidOS tries to provide a level of protection by asking the user to validatecertain permissions like SMS receive/send internet access, etc. However,this information is not sufficient for the user to make a deterministicdecision on the threat the application poses.

One solution currently available for the Android OS provides a tainttracking and analysis system capable of simultaneously tracking multiplesources of sensitive data. The solution provides real time analysis byleveraging Android OS's virtualized execution environment. The solutionmodifies the Android OS's application verification platform to track theflow of privacy sensitive information by automatically labeling datafrom privacy-sensitive sources. When labeled data is transmitted overthe network, or otherwise leaves the mobile device, the solution logsthe data's labels, the application responsible for transmitting thedata, and the data's destination. However, the solution does not preventthe applications from sending the sensitive data. Moreover, users may bedisturbed as they are informed any time the data has been sent. Thesolution may also add a significant overhead. Typical mobile devices cannot tolerate the platform changes required and overheads of thesolution.

A system for providing threshold levels on privileged resource usageoutlined by FIG. 1 can resolve these issues, among others. Embodimentsof the present disclosure seek to vastly improve capabilities ofexisting technologies to allow for a more robust solution. The exampleembodiment of FIG. 1 illustrates active intervention, wherein at eachrequest to access a privileged source of information, or each use of aprivileged resource, the cumulative usage of that particular resource orsource of information for the application may be collected, andthreshold levels applied. As used herein, “cumulative usage” of aresource is a sum of usage of the resource. Cumulative usage may beabsolute (e.g., sum of number of times a resource is used), oralternatively, may be calculated over any desired parameter, such astime (e.g., sum of usage over a predefined time period), sessions (e.g.,sum of usage over a discrete number of sessions), etc. If required, theuser can be notified that the application has reached the thresholdlevel on usage of a particular resource or source of information. Theuser can then choose a relevant action to be taken. The user may providefeedback to the system by modifying the rules if there is a perceivedneed to do so. Components of system 10 may not allow the request to passthrough if the rules specify that the request should be blocked.

In example embodiments, components of system 10 may set threshold levels22, and user 26 may be notified whenever requests 16 from applications12 exceed threshold levels 22. In an example embodiment, user 26 may setthreshold level 22 for an applicable rule. For example, rules/filtersmodule 20 may present a rule to user 26 to set a file size thresholdlevel for outgoing email attachments. In another example embodiment,threshold level 22 may be set automatically according to a rule and/orfilter set by user 26. For example, user 26 may set a rule for energysavings. The rule may automatically set threshold level 22 for batteryusage at 50%.

According to one embodiment, each request 16 by application 12 to accessprivileged resources 18 may be intercepted and subjected to one or morerules, for example, including threshold level 22. User 26 may benotified appropriately, for example, when request 16 indicates thatapplicable threshold level 22 (e.g., on usage of a particular resource18) has been reached. User 26 may choose a suitable action to takeregarding request 16. According to another embodiment, each request 16by application 12 to access privileged resources 18 may be entered intolog 36 of utilization database 38.

In an example embodiment, network data sent by applications 12 may bemonitored and threshold level 22 set in rules/filters module 20. Forexample, threshold level 22 for outgoing network data may be set at 5 kbper day, and if application 12 exceeds 5 kb of network data, user 26 maybe notified (e.g., via notification 24). Assume, for the sake ofillustration, that a malicious application 12 uses the mobile device tosend out spam advertisement emails to recipients listed on a contactlist. Malicious application 12 may send request 16 to resource 18comprising a network interface, requesting to send the spamadvertisement over the network. Monitoring and blocking module 14 maycollect information about the amount of network data that maliciousapplication 12 is sending over a period of time, compare the collectedinformation with threshold level 22, and block request 16 if thresholdlevel 22 is exceeded. In an example embodiment, rules/filters module 20may inform user 26 via notification 24 that application 12 has exceededthreshold level 22. User 26 can modify the rule to increase thresholdlevel 22 for application 12, or blacklist application 12 so that itcannot use the network in the future, or if user 26 determines thatapplication 12 is malicious, then application 12 can be uninstalled fromthe mobile device.

In another example embodiment, threshold level 22 for processor usagemay be set at 5% over a 5 minute period, so that if application 12exceeds threshold level 22 in processor usage, user 26 may be notified(e.g., via notification 24). Assume, for the sake of illustration, thatuser 26 installs application 12, which uses 50% of processor 32.Monitoring and blocking module 14 may intercept request 16 to accessprocessor 32, compare processor usage with threshold level 22, and blockrequest 16 if threshold level 22 has been exceeded. In an exampleembodiment, rules/filters module 20 may inform user 26 via notification24 that application 12 has exceeded threshold level 22. Further requests16 to access processor 32 may be blocked waiting for user intervention.

In yet another example embodiment, user 26 may unintentionally install amalware application 12 from a marketplace. For example, application 12may masquerade as a legitimate game. However, the primary function ofapplication 12 may be to send spam short message services (SMSs) toother phones from the mobile device. For example, every day, application12 may send out 50 SMSs from the mobile device. Threshold level 22 maybe set to monitor the number of SMSs sent from the mobile device.Further threshold levels 22 can take into consideration a number of SMSssent to contacts in the user's address book, and the number of SMSs sentto people outside the user's address book. Once user 26 is notified ofthe activity, user 26 can disallow application 12 (or any otherapplication) from sending SMSs to contacts other than those present inthe mobile device's address book; disallow application 12 from sendingSMSs to contacts in the user's address book; uninstall application 12;and/or block application 12 from sending any further SMSs.

In yet another example embodiment, user 26 may install application 12that requests numerous permissions to access various privilegedresources. However, application 12 may rarely, if ever, use some of thepermissions that it has requested. A rule may be set to sendnotification 24 to user 26 if application 12 has not used a grantedpermission for a predefined time period (e.g., at least a week).Monitoring and blocking module 14 may monitor the permissions used byapplication 12 over the predefined time period. If any permissions havenot been used for over the predefined time period, user 26 may benotified. User 26 can then remove the unused permission from application12. This may ensure that if any vulnerability exists in application 12,then an exploit cannot gain access to any resource 18 protected by thepermission.

Turning to FIG. 2, FIG. 2 is a simplified flow-chart illustratingexample operational steps that may be associated with embodiments of thepresent disclosure. Embodiments of the present disclosure may intervenein application communications (e.g., requests 16) with an operatingsystem of the mobile device, apply rules, and notify user 26 ifrequired. User 26 may then provide feedback to system 10 by modifyingthe rules if needed. Components of system 10 may not allow request 16 topass through if the rules suggest that the request should be blocked.

Operations 50 may begin in 52, when system 10 is activated. In 54,application 12 sends request 16 to access resource 18. In 56, request 16is logged into log 36 in utilization database 38. In 58, existing set ofrules may be applied from rules database 30. If rules allow access,monitoring and blocking module 14 may allow the access to proceed in 60and the operations may stop at 62. On the other hand, if the rules donot allow access, the access may be blocked in 64 and the operationstops in 66. If no rules are present, or rules indicate user 26 shouldbe notified, then when user 26 is notified, user 26 may specify anaction to be taken in 68. For example, user 26 may block or allowaccess, or may update the rules in rules database 30. The operations maystop in 70.

Turning to FIG. 3, FIG. 3 is a simplified block diagram illustratinganother example implementation of a system 10 for providing thresholdlevels on privileged resource usage. The example embodiment of FIG. 3illustrates passive intervention, wherein at each request to access aprivileged source of information, or each use of a privileged resource,an entry to a database (maintained by system 10) may be made. Atspecific time periods (e.g., regular intervals), a background daemon mayread the database, collate the entries, and notify the user as and whenrequired. The user can provide feedback regarding the rules and/orthreshold levels if there is a perceived need to do so.

A mobile device may be provisioned with one or more applications 12. Amonitoring and blocking module 14 may be provisioned to intercept one ormore requests 16 from applications 12 to access one or more resources18. Monitoring and blocking module 14 may log request 16 into log 36 inutilization database 38. A daemon 80 may periodically check utilizationdatabase 38, collate the information therein, analyze it (e.g., byapplying rules from rules/filters module 20) and notify user 26 with anotification 24, if required. User 26 can provide feedback throughupdate 28. User 26 may send update 28 directly to monitoring andblocking module 14 or update rules in rules/filters module 20. Ifrequest 16 is permitted by the rules, or by update 28, request 16 may beforwarded to resource 18.

Turning to FIG. 4, FIG. 4 is a simplified flow-chart illustratingexample operational steps that may be associated with embodiments of thepresent disclosure. Operations 100 begin in 102, when system 10 isactivated. In 104, application 12 sends request 16 to access privilegedresource 18. Request 16 is logged into log 36 in utilization database 38in 106. Log 36 may contain one or more requests 16 (e.g., from previousaccess attempts, or from other applications). Daemon 80 may read log 36in 108. Daemon 80 may analyze log 36 in 110. A determination may be madein 112 whether log 36 (e.g., any information therein) requires userattention. If user attention is required, notification 24 is sent touser 26 in 114. User 26 may decide to update rules in 116. If user 26decides to update the rules, update 28 may be made to rules database 30in 118. After database 30 has been updated, or if user 26 decides not toupdate the rules, daemon 80 may sleep for a while in 120. The daemonprocess may then revert to 108.

With reference again to the processing of application 12, monitoring andblocking module 14 may apply an existing set of rules from rulesdatabase 30 to request 16 in 122. The existing set of rules may comprisethe original set of rules and any updates made by user 26. If the rulesallow access, access is allowed in 124 and the operations stop at 126.If the rules do not allow access, access is blocked in 128, and theoperations stop at 130.

Although the embodiments described herein have referred to mobileapplications, it will be apparent that other sets of program files maybe evaluated and/or remediated using system 10. The options forthreshold levels on privileged resource usage as shown in FIGURES, arefor example purposes only. It will be appreciated that numerous otheroptions, at least some of which are detailed herein in thisSpecification, may be provided in any combination with or exclusive ofthe options of the various FIGURES.

Software for providing threshold levels on privileged resource usage canbe provided at various locations (e.g., within monitoring and blockingmodule 14). In one example implementation, this software is resident ina mobile device sought to be protected from a security attack (orprotected from unwanted, or unauthorized manipulations of a writeablememory area). In a more detailed configuration, this software isspecifically resident in a security layer of an operating system, whichmay include (or otherwise interface with) the components depicted byFIG. 1. In still other embodiments, software could be received ordownloaded from a web server (e.g., in the context of purchasingindividual end-user licenses for separate devices, applications, etc.)in order to provide this security protection.

In other examples, the functions described herein could involve aproprietary element (e.g., as part of an antivirus solution), whichcould be provided in (or be proximate to) these identified elements, orbe provided in any other device, server, network appliance, console,firewall, switch, information technology (IT) device, etc., or beprovided as a complementary solution (e.g., in conjunction with afirewall), or provisioned somewhere in the network. As described herein,mobile devices may include any suitable hardware, software, components,modules, interfaces, or objects that facilitate the operations thereof.This may be inclusive of appropriate algorithms and communicationprotocols that allow for the effective security protection. In addition,the functions described herein can be consolidated in any suitablemanner. Along similar design alternatives, any of the illustratedmodules and components of the various FIGURES may be combined in variouspossible configurations: all of which are clearly within the broad scopeof this Specification.

Any of these elements can include memory for storing information to beused in achieving the operations as outlined herein. Additionally, themobile devices may include a processor that can execute software or analgorithm to perform the activities as discussed in this Specification.The mobile devices may further keep information in any suitable memory(random access memory (RAM), ROM, EPROM, EEPROM, ASIC, etc.), software,hardware, or in any other suitable component, device, element, or objectwhere appropriate and based on particular needs. The information beingtracked, sent, received, or stored in system 10 could be provided in anydatabase, register, table, cache, queue, control list, or storagestructure, based on particular needs and implementations, all of whichcould be referenced in any suitable timeframe.

Any of the memory items discussed herein should be construed as beingencompassed within the broad term ‘memory.’ Similarly, any of thepotential processing elements, modules, and machines described in thisSpecification should be construed as being encompassed within the broadterm ‘processor.’ Each of the mobile devices, computers, networkappliances, etc. can also include suitable interfaces for receiving,transmitting, and/or otherwise communicating data or information in asecure environment.

A processor can execute any type of instructions associated with thedata to achieve the operations detailed herein in this Specification. Inone example, the processor (as shown in the FIGURES) could transform anelement or an article (e.g., data) from one state or thing to anotherstate or thing. In another example, the activities outlined herein maybe implemented with fixed logic or programmable logic (e.g.,software/computer instructions executed by a processor) and the elementsidentified herein could be some type of a programmable processor,programmable digital logic (e.g., a field programmable gate array(FPGA), an erasable programmable read only memory (EPROM), anelectrically erasable programmable ROM (EEPROM)) or an ASIC thatincludes digital logic, software, code, electronic instructions, or anysuitable combination thereof.

In certain example implementations, the functions outlined herein may beimplemented by logic encoded in one or more tangible non-transitorymedia (e.g., embedded logic provided in an application specificintegrated circuit (ASIC), digital signal processor (DSP) instructions,software (potentially inclusive of object code and source code) to beexecuted by a processor, or other similar machine, etc.). In some ofthese instances, memory (as shown in the FIGURES) can store data usedfor the operations described herein. This includes the memory being ableto store software, logic, code, or processor instructions that areexecuted to carry out the activities described in this Specification.

These elements and/or modules can cooperate with each other in order toperform the activities as discussed herein. In other embodiments, thesefeatures may be provided external to these elements, included in otherdevices to achieve these intended functionalities, or consolidated inany appropriate manner. For example, some of the processors associatedwith the various elements may be removed, or otherwise consolidated suchthat a single processor and a single memory location are responsible forcertain activities. In a general sense, the arrangement depicted inFIGURES may be more logical in its representation, whereas a physicalarchitecture may include various permutations, combinations, and/orhybrids of these elements. In various embodiments, some or all of theseelements include software (or reciprocating software) that cancoordinate, manage, or otherwise cooperate in order to achieve theoperations outlined herein.

In certain example implementations, the activities outlined herein maybe implemented in software. In various embodiments, the software of thesystem described herein could involve a proprietary element, which couldbe provided in (or be proximate to) these identified elements, or beprovided in any other device, server, network appliance, console,firewall, switch, information technology (IT) device, distributedserver, etc., or be provided as a complementary solution, or otherwiseprovisioned in the network.

Note that with the numerous examples provided herein, interaction may bedescribed in terms of two, three, four, or more network elements andmodules. However, this has been done for purposes of clarity and exampleonly. It should be appreciated that the system can be consolidated inany suitable manner. Along similar design alternatives, any of theillustrated modules, components, and elements of FIG. 1 may be combinedin various possible configurations, all of which are clearly within thebroad scope of this Specification. In certain cases, it may be easier todescribe one or more of the functionalities of a given set of flows byonly referencing a limited number of elements or components. It shouldbe appreciated that the system of FIG. 1 (and its teachings) is readilyscalable and can accommodate a large number of components, as well asmore complicated/sophisticated arrangements and configurations.Accordingly, the examples provided should not limit the scope or inhibitthe broad teachings of system 10 as potentially applied to a myriad ofother architectures.

It is also important to note that the operations described withreference to the preceding FIGURES illustrate only some of the possiblescenarios that may be executed by, or within, the system. Some of theseoperations may be deleted or removed where appropriate, or these stepsmay be modified or changed considerably without departing from the scopeof the discussed concepts. In addition, the timing of these operationsmay be altered considerably and still achieve the results taught in thisdisclosure. The preceding operational flows have been offered forpurposes of example and discussion. Substantial flexibility is providedby the system in that any suitable arrangements, chronologies,configurations, and timing mechanisms may be provided without departingfrom the teachings of the discussed concepts.

What is claimed is:
 1. A method comprising: detecting a request by anapplication in a mobile device to access a privileged resource;determining a cumulative usage of the privileged resource by theapplication; and performing an action according to a rule if apredefined threshold level of usage triggers the action based on thecumulative usage.
 2. The method of claim 1, wherein the action includes:blocking the request; and sending a notification to a user.
 3. Themethod of claim 1, wherein the action includes updating a rules databaseto modify the predefined threshold level of usage associated with therule.
 4. The method of claim 1, wherein the predefined threshold levelof usage triggers the action if the cumulative usage occurs within apredefined amount of time.
 5. The method of claim 1, wherein thepredefined threshold level of usage triggers the action if thecumulative usage exceeds the predefined threshold level of usage.
 6. Themethod of claim 1, further comprising: monitoring permissions of theapplication to the privileged resource; and removing any permissionsthat have not been used for a predefined time period.
 7. The method ofclaim 6, further comprising sending a notification to a user if theapplication has not used a permission for the predefined time period. 8.The method of claim 1, further comprising: sending a notification to theuser if there are no rules applicable to the request.
 9. The method ofclaim 1, further comprising: logging the request into a log in autilization database.
 10. The method of claim 9, further comprising:reading the log; collating information in the log; and analyzing thelog.
 11. An apparatus comprising: a memory configured to store data; anda processor operable to execute instructions associated with the data; amonitoring and blocking module; and a rules module, such that theapparatus is configured for: detecting a request by an application in amobile device to access a privileged resource; determining a cumulativeusage of the privileged resource by the application; and performing anaction according to a rule if a predefined threshold level of usagetriggers the action based on the cumulative usage.
 12. The apparatus ofclaim 11, wherein the action includes: blocking the request; and sendinga notification to a user.
 13. The apparatus of claim 11, wherein theaction includes updating a rules database to modify the predefinedthreshold level of usage associated with the rule.
 14. The apparatus ofclaim 11 further configured for: monitoring permissions of theapplication to the privileged resource; and removing any permissionsthat have not been used for a predefined time period.
 15. The apparatusof claim 11, the apparatus further comprising a utilization database forlogging the request into a log, wherein the apparatus is furtherconfigured for: reading the log; collating information in the log; andanalyzing the log.
 16. Logic encoded in non-transitory media thatincludes code for execution and when executed by a processor is operableto perform operations comprising: detecting a request by an applicationin a mobile device to access a privileged resource; determining acumulative usage of the privileged resource by the application; andperforming an action according to a rule if a predefined threshold levelof usage triggers the action based on the cumulative usage.
 17. Thelogic of claim 16, wherein the action includes: blocking the request;and sending a notification to a user.
 18. The logic of claim 16, whereinthe action includes updating a rules database to modify the predefinedthreshold level of usage associated with the rule.
 19. The logic ofclaim 16, the operations further comprising: monitoring permissions ofthe application to the privileged resource; and removing any permissionsthat have not been used for a predefined time period.
 20. The logic ofclaim 16, the operations further comprising: logging the request into alog in a utilization database; reading the log; collating information inthe log; and analyzing the log.